HADOOP-18740. S3A prefetch cache blocks should be accessed by RW locks#5675
HADOOP-18740. S3A prefetch cache blocks should be accessed by RW locks#5675steveloughran merged 4 commits intoapache:trunkfrom
Conversation
|
All failures related to HADOOP-18744 |
|
💔 -1 overall
This message was automatically generated. |
|
I want to implement a new cache replacement algorithm in hdfs but I don't know which part of module to use and modify. Can any one please help me find the modules and functions which need to override to add my own caching replacement algorithm in hdfs |
|
@MayankSinghParmar get on the hadoop hdfs mailing list and discuss there. @virajjasani can you rebase and retest? |
steveloughran
left a comment
There was a problem hiding this comment.
core changes look good, just a nit about using this. where it isn't needed.
I'm worried about concurrency of close(), where
- we should make the
closedflag atomic boolean; only execute close on the first call and have all the other ops fail if closed - be confident that locking in close() is good. After the disaster with the abfs prefetcher, we need to look carefully here
| */ | ||
| void takeLock(LockType lockType) { | ||
| if (LockType.READ == lockType) { | ||
| this.lock.readLock().lock(); |
| */ | ||
| void releaseLock(LockType lockType) { | ||
| if (LockType.READ == lockType) { | ||
| this.lock.readLock().unlock(); |
| int numFilesDeleted = 0; | ||
|
|
||
| for (Entry entry : blocks.values()) { | ||
| entry.takeLock(Entry.LockType.WRITE); |
There was a problem hiding this comment.
should we be acquiring locks in close()?
good: no race condition in close
bad) the usual
also, L303: should closed be atomic?
There was a problem hiding this comment.
also, L303: should closed be atomic?
+1 to this suggestion, let me create a separate patch with HADOOP-18756 to better track it.
good: no race condition in close
bad) the usual
sounds reasonable, let me try setting timeout
|
Test results are clean |
|
💔 -1 overall
This message was automatically generated. |
|
|
||
| for (Entry entry : blocks.values()) { | ||
| entry.takeLock(Entry.LockType.WRITE); | ||
| boolean lockAcquired = entry.takeLock(Entry.LockType.WRITE, 5, TimeUnit.SECONDS); |
There was a problem hiding this comment.
pull the number into a constant. Know that I automatically -1 all inline constants in production code and save time all round.
There was a problem hiding this comment.
my bad, let me fix this real quick
| * @param unit the time unit of the timeout argument. | ||
| * @return true if the lock of the given lock type was acquired. | ||
| */ | ||
| boolean takeLock(LockType lockType, long timeout, TimeUnit unit) { |
There was a problem hiding this comment.
should this and the others be private? you don't want other classes playing with your lock code...
There was a problem hiding this comment.
sounds good, done
|
💔 -1 overall
This message was automatically generated. |
steveloughran
left a comment
There was a problem hiding this comment.
+1. concurrency stuff always worries me, but this looks good
#5675) Contributed by Viraj Jasani
Jira: HADOOP-18740